Thanks for the suggestions, Bradley. We'll take a look at the UISheetPresentationController approach as a replacement for our current popovers. As you say, it's annoying spending time repairing functionality that has been fine for many years, and suddenly doesn't work anymore. We'd always prefer to be adding new features for our customers. Cheers!

This is a pretty awful change, as Apple hasn't defined what “large” means. So our existing popover view controllers with translucent background suddenly start showing an opaque background when they exceed some arbitrary size? I noticed this on a popover alert which shows a transparent background running in English, but an opaque background running in German, because the latter is slightly more verbose and takes up a slightly larger amount of screen. An App should never change the presentation style just because the user's selected language is different. Our specific scenario is presenting alerts as popovers above an Augmented Reality view. It is important to us that the user doesn't lose sight of their AR environment, which is why we want to preserve the transparent background of the popover. Apple has a great track record for preserving backward compatibility, but this time it's broken. Even if this is the new "default" behaviour, it would really help if we could disable it programmatically for scenarios where we really do not want the OS to make such an arbitrary change in presentation. Please consider amending the API so we can either disable or "tune" this new presentation style to preserve our existing UI appearance.

Did you ever get an answer to this problem? It's something we have struggled with since the iOS 17 release and it seems to still be a problem with the iOS 18 beta 3. We're using a TIF container for the Depth Map, feeding this into the PhotogrammetrySample, but still we get this error message. We also see incorrect scale in the resulting USDZ models, but the scale isn't consistently too small or too large ... it seems fairly random.

I have been battling with the same issues. I have tried feeding a folder to the PhotogrammetrySession and also feeding it a sequence of PhotogrammetrySamples. Either way I always seem to get a resulting 3D model that is proportioned correctly, but is oriented on a skew angle or sometimes even upside down. Supplying gravity vectors seems to have zero effect on the result, so I'm not sure if they simply are unused or if they aren't used to orient the model. Apple's sample app seems to magically embed the gravity vector inside the HEIC file's metadata, as a result of the way the image itself is recorded using AVFoundation. But I'm recording the images inside an ARKit session, and the HEIC snapshots provided by ARKit don't include that EXIF gravity vector. Did you find any solutions to this problem?

I also noticed this with beta 3 of XCode 13.3. The beta of XCode would crash its build system and you'd have to reboot before it could compile again. So I switched back to the production version (13.2.1) and continued using that for the past week. But as of this morning (16th March) it looks like macOS decided to auto-update and my default version of Xcode is now 13.3 (release). And guess what? It still crashes its own build system with these (incorrect) build cycle errors and it's now totally unusable. Anyone know how to revert to a previous working version of Xcode?